Zusammenfassung von Kemper/Eickler, Datenbanksysteme, 5. Auflage, Kapitel 4-14

Geschrieben von Christian Pcher

Verffentlicht unter Creative Commons Attribution-ShareAlike 2.0 Germany License. (http://creativecommons.org/licenses/by-sa/2.0/de/) ==> Erweitert und verbessert die Zusammenfassung!


Kap 4: Relationale Anfragesprachen

* Anfragesprachen, wie SQL, sind deklarativ.
* Schema definieren: CREATE TABLE ...
* Schema ndern: ALTER TABLE ... [ADD |ALTER COLUMN] ...
* Datensatz einfgen: INSERT INTO ... VALUES ...
* Anfrage: SELECT DISTINCT ... FROM ... WHERE ... ORDER BY ... [DESC|ASC]
* Aggregatfunktionen: AVG, MIN, MAX, SUM, COUNT
* HAVING: Geht nur bei GROUP BY, selektiert ganze Gruppen.
* Mengenoperatoren: UNION, INTERSECT, EXCEPT, IN, NOT IN
* Datensatz ndern: UPDATE ... SET ...
* Datensatz lschen: DELETE FROM ... WHERE ...
* nderungen werden erst in tempore Tabelle oder in 
* SQL hat keinen Allquantor, Existenzquantor durch EXISTS
* SQL hat relationales Tupelkalkl als Grundlage
* null bedeutet "korrekter Wert nicht bekannt"
* dreiwertige Logik: true, false, unknown
* vier Arten Joins: cross join, natural join, (inner) join, left/right/full outer join
* SQL nicht Touring-vollstndig: Keine Rekursion mglich! Keine transitive Hlle
* Sichten: CREATE VIEW ... AS ...
* Zweck von Sichten: a) Daten fr bestimmte Benutzer (un-)zugnglich machen, b) vereinfachte Schreibweise fr Anfragen
* Sichten sind update-fhig, wenn a) keine Aggregatfunktionen, DISTINCT, HAVING benutzt werden, b) Schlssel der Basisrelation enthalten ist und c) nur eine Tabelle verwendet wird.
* Generalisierung kann erreicht werden, wenn Obertyp oder Untertyp durch Views definiert werden.
* Einbettung in Wirtssprachen durch Strings (JDBC) oder Metasprache und Prprozessor (SQLJ)


Zusammenfassung Kapitel 5: Datenintegritt

* Syntaktische Integrittsbedingungen schon durch Tabellendefinition bestimmt, jetzt semantische Integrittsbedingungen
* vier Arten: a) referentielle I., b) statische I. durch CHECK, c) Contraints, d) Trigger
* referentielle Integritt: Fremdschlssel null oder Fremdschlssel = Primrschlssel eines Datensatzes der referenzierten Tabelle
* statische Integritt: CHECK (Note BETWEEN 0.7 AND 5.0)
* CHECK auch ok, wenn Antwort unknown
* Constraints: In Tabellendefinition CONSTRAINT Name CHECK (EXISTS (SELECT ...))
* Trigger: 4 Teile, a) Name, b) Auslser (BEFORE UPDATE ON ... FOR EACH ROW), c) einschrnkende Bedingung (WHEN), d) Prozeduraler Code


Zusammenfassung Kapitel 6: Relationale Entwurfstheorie

* jetzt: Konzeptuelle Feinabstimmung, Gte des Schemas verbessern
* Functional Dependency (FD): alpha --> beta gilt, wenn Werte von beta durch Werte von alpha bestimmt werden.
* FDs stellen eine semantische Konsistenzbedingung dar, d.h. sie mssen durch das DBMS erzwungen werden.
* alpha ist Superschlssel, wenn alpha --> R, d.h. die Werte von alpha bestimmen alle anderen Attributwerte
* alpha ist Kandidatenschlssel, wenn alpha -*-> R
* beta ist voll funktional von alpha abhngig (alpha -*-> beta), wenn alpha --> beta und alpha nicht mehr verkleinert werden kann.
* F+ Hlle der FDs, Herleitung durch Armstrong Axiome: 
   a) Falls beta Teilmenge von alpha, gilt alpha --> beta
   b) Verstrkung: alpha --> beta ==> alpha gamma --> beta gamma
   c) Transitivitt
* Mengen von funktionalen Abhngigkeiten sind quivalent, wenn ihre Hllen gleich sind. Man schreibt F==G.
* F_c heisst kanonische berdeckung zu F, wenn
   a) F+_c = F+
   b) Man kann weder alpha noch beta verkleinern, es gibt keine berflssigen Attribute.
   c) Jede linke Seite in F_c ist eindeutig.
* Berechnung der kanonischen berdeckung durch 
   a) Linksreduktion (Kann man bei FD alpha --> beta ein A von alpha entfernen?)
   b) Rechtsreduktion (B bei beta entfernbar?)
   c) Entferne FDs der Form alpha --> {}
   d) Fasse FDs mit gleicher linken Seite durch Vereinigungsregel zusammen.
* Drei Anomalien:
   a) Update: Wenn Information redundant, dann kann bei Update eines vergessen werden. Zustzlich hherer Speicher- und CPU-Bedarf
   b) Einfge: Informationen zweier Entities werden vermischt. Auffllen mit NULL ntig.
   c) Lsch: unabsichtliches Lschen von Daten wegen Vermischung
* Korrektheitskriterien fr Schemazerlegungen:
   a) Verlustlosigkeit: nach Projektion und natrlichem Join muss wieder das gleiche rauskommen.
   b) Abhngigkeitserhaltung: alle FDs mssen auch nach Zerteilung gelten.
* 1NF: Alle Attribute haben atomare Wertebereiche
* 2NF: Jedes Nichtschlssel-Attribut ist voll funktional abhngig von jedem Kandidatenschlssel
* 3NF: Fr jede FD alpha --> B gilt mind. eine der Bedingungen:
   a) B ist Element von alpha (FD ist trivial)
   b) B ist in einem Kandidatenschlssel enthalten.
   c) alpha ist Superschlssel der Relation.
* Berechnung der 3NF:
   1) Berechne kanonische berdeckung.
   2) Kreiere fr jede FD ein Relationsschema.
   3) Whle Schlssel.
   4) Eliminiere Schematas, die vollstndig in anderem Schema enthalten sind.
* BCNF: Wie 3NF, aber ohne Bedingung b). Nicht abhngigkeitsbewahrend.
* multivalued dependencies (MVD): beta ist mehrwertig abhngig alpha (alpha -->-> beta) gdw. man kann bei geichem alpha-Wert die beta-Werte vertauschen und das resultierende Tupel ist weiter in der Relation.
* Zerlegungen von Relationen mit MVDs: R kann in R1, R2 zerlegt werden, wenn a) R = R1 vereinigt mit R2 und b) R1 geschnitten R2 -->-> R1 oder R1 geschnitten R2 -->-> R2
* alpha -->-> beta ist trivial, wenn beta Teilmenge von alpha oder beta = R - alpha
* 4NF: Fr jede MVD gilt: a) MVD ist trivial oder b) alpha ist Superschlssel fr R. Nicht abhngigkeitsbewahrend.


Zusammenfassung Kap 7 Indexstrukturen

* ISAM: Wie Daumenindex. Suchen in log(n), Insert und Delete kann Index komplett nach rechts verschieben. Bild siehe S.206
* B-Baum vom Grad k: Jeder Knoten ausser der Wurzel hat zwischen k und 2k Eintrge. Bltter alle gleich weit von Wurzel entfernt. Zugriffe sehr stark logarithmisch.
* B+-Baum: "hohler Baum", Daten nur in Blttern.
* Hashing: Index durch Hashfunktion, z.B. h(x) =  x mod p. Problem: berlaufende Seiten fhren zu Ineffizienz.
* Erweiterbares Hashing: h(x) wird binr dargestellt. Prefix als Verzeichniseintrag. Reicht eine Seite nicht mehr aus, wird weitere Stelle zu Prefix hinzugenommen. => doppelte Anzahl Seiten.
* R-Baum: Boxen um n-dimensional Daten bauen.
* Range Queries knnen von Hashes nicht gut bearbeitet werden. Bei Exact Match Queries sind sie aber Bumen berlegen.


Zusammenfassung Kap 8 Anfragebearbeitung

* Ziel: Anfrageoptimierung, dazu logische und physische Optimierung
* Regeln zur logischen Optimierung schreiben Anfrage in RA um, z.B. kann Selektion und Kreuzprodukt zu einem Join zusammengefasst werden
* exakte Optimierung so schwer wie das originale Problem, aber Optimierungsheuristiken mglich:
  - Aufbrechen von Selektionen
  - Verschieben der Selektionen nach unten im Baum
  - Zusammenfassen von Selektionen und Kreuzprodukten zu Joins
  - Reihenfolge der Joins, so dass kleine Zwischenergebnisse
  - Einfgen von Projektionen
  - Verschieben der Projektionen nach unten im Baum
* Implementierung von Joins:
  - nested loops
  - seitenorientiertes nested loops
  - Merge Join (zwei Pointer wandern runter)
  - Hash Join
* Durch Kostenmodelle werden Implementierungen ausgewhlt und daraus Auswertungsplne erstellt.
* Statistiken werden durch ANALYSE gesammelt
* den Auswertungsplan kriegt man mit EXPLAIN



Zusammenfassung Kap9 Transaktionsverwaltung

* Transaktion: Arbeitseinheit in einer Anwendung
* ACID:
        - Atomicity: Transaktion als kleinste, nicht teilbare Einheit, "ganz oder gar nicht"
        - Constistency: Nach Beendigung von Transaktion ist Datenbasis konsitent
        - Isolation: nebenlufige Transaktionen beeinflussen sich nicht
        - Durability: Wirkungen abgeschlossener Transaktionen bleiben dauerhaft bestehen
* Recovery: kmmert sich um Atomicity und Durability
* Mehrbenutzersynchronisation: kmmert sich um Isolation


Kapitel 10: Fehlerbehandlung
============================

* lokales Undo: treten im normalen Betrieb auf, z.B. durch Fehler im Anwendungsprogramm oder durch ABORT.
* globales Undo: Nach Hauptspeicherverlust nicht abgeschlossene Transaktionen rckgngig machen.
* globales Redo: Nach Hauptspeicherverlust abgeschlossene Transaktionen auf Festplatte schreiben.
* steal/not steal: Pufferspeicher, der durch aktive Transaktionen bentigt ist kann (nicht) ersetzt werden. Macht globales Undo ntig.
* force/not force: nderungen einer Transaktion werden bei COMMIT (nicht) auf die Festplatte geschrieben. Macht globales Redo ntig.
* Einbringstrategie:
  - update-in-place: Seite auf Festplatte wird berschrieben.
  - Twin-Block: zwei Seiten und Markierung welche Seite aktuell ist.
* Log:
  - LSN: Sequenz Number
  - TransaktionsID
  - PageID
  - PrevLSN: vorheriger Log aus gleicher Transaktion.
* Write Ahead Logging (WAL): Erst Logs schreiben, dann Daten auf Festplatte schreiben.
* Wiederanlauf:
  - Analyse des Logs, Bestimme Winner und Looser
  - Redo von Winnern und Loosern
  - Undo von Loosern


Kapitel 11: Mehrbenutzersynchronisation
=======================================

* Interleaving von Transaktions kann Wartezeiten berbrcken.
* Lost Update: T1 berschreibt nderungen von T2.
* Dirty Read: T1 liest Daten von T2 bevor T2 zurckgesetzt wird.
* Phantom Read: T1 erstellt Daten, die von T2 nicht mehr bercksichtigt werden. 
* Schedule: Ablauf einer verzahnten Ausfhrung mehrerer Transaktionen. Bestimme partielle Ordnung fr Konfliktoperatioenen.
* Schedules serialisieren: Vertauschen von Operationen, bis Transaktionen nacheinander laufen.
* serialisierbare Schedules: Ein Schedule ist serialisierbar, wenn es quivalent zu einer seriellen Historie ist.
* Serialisierbarkeitstheorem: Schedule ist serialisierbar, gdw. wenn der Serialisierungsgraph azyklisch ist.
* Rcksetzbare Schedules: Ermglichen ABORT ohne andere Transaktionen in Mitleidenschaft zu ziehen. Problematisch ist, wenn T1 schreibt und T2 das danach liest.
* Schedules ohne kaskadierendes Rcksetzen: nderungen von T1 werden erst nach COMMIT freigegeben.
* Scheduleklassen: S. 308
* Locks: Shared/Read, eXclusive/Write
* Two Phase Locking:
  - Jedes Objekt muss vor Benutzung gesperrt werden
  - Keine Transaktion fordert Sperren zweimal an
  - Lock nicht gekriegt -> Warteschlange
  - Erst Wachstumsphase, dann Schrumpfungsphase
* strenges 2PL: Alle Locks werden erst beim Ende der Transaktion freigegeben.
* 2PL garantiert Serialisierbarkeit, strenges 2PL schtzt vor kaskadierenden Rollback
* Deadlock-Erkennung:
  - Time-out
  - Wartegraph (Zykel = Deadlock)
  - Preclaim (Alle Locks am Anfang nehmen)
  - Zeitstempel (wound-wait, wait-die)
* Wound-Wait: T1 fordert Lock an, das T2 hat. Wenn T1 lter als T2, verwunde T2. Sonst wartet T1.
* Wait-Die: Wenn T1 lter als T2, wartet T1. Sonst stirbt T1.
* Isolation-Levels:
  - read uncommitted (liest auch uncommitted values)
  - read committed (Problem: non repeatable read)
  - repeatable read
  - serializable

Kapitel 12: Sicherheitsaspekte
==============================

* drei Arten:
  - Identifikation
  - Zugriffskontrolle
  - Auditing (Logs angucken)
* Discretionary Access Control (DAC): Quintupel (Objekte, Benutzer, Rechte, Filterprdikat, Weitergabeflag)
* Mandatory Access Control (MAC): Jeder User hat ein Clearance-Level. Objekte haben ein Classification-Level.
* Multilevel Datenbanken:
  - Jedes Attribut und das ganze Tupel zustzlich haben Classification.
  - Polyinstatierung: Tupel darf mit mehreren Sicherheitseinstufungen vorkommen.


Zusammenfassung Kapitel 13: OODB

* Schwachpunkte relationaler DBs:
        - Anwendungsobjekt wird auf unterschiedliche Relationen segmentiert.
        - Knstliche Schlsselattribute
        - Kein Verhalten
        - Impedance Mismatch: Mengenorientiert vs. Satzorientiert
* Vorteile OO-Modellierung:
        - Information Hiding: Operationen ausfhrbar ohne Kenntnis der
Reprsentation der Daten
        - Transformationen entfallen (Mengenorientiert vs. Satzorientiert)
        - Objektidentitt statt knstlicher Schlssel
* Drei Bestandteile eines Objektes:
        - Identitt (OID)
        - Typ
        - Wert
* Drei Bestandteile eines Objekttyps:
        - Strukturbeschreibung (Attribute)
        - Verhaltensbeschreibung (Operationen)
        - Generalisierungs-/Spezialisierungsbeziehungen
* Nachteile von "identity through contents":
        - Objekte mit gleichem Wert mssen nicht identisch sein.
        - knstliche Schlssel mssen vom Benutzer gewartet werden, obwohl keine Anwendungssemantik.
        - Schlssel drfen nicht verndert werden
* OIDs = Objekt-Referenzen
* Beziehungen in ODMG ber RELATIONSHIP und INVERSE
        CLASS Professoren {
                RELATIONSHIP Rume residiertIn INVERSE Rume::beherrbergt;
        };
* Soll eine Seite N-wertig sein definiert man
        RELATIONSHIP set <Vorlesungen> liest inverse Vorlesungen::gelesenVon
* INVERSE garantiert Symmetrie
* Extent ist die Menge aller Instanzen eines Objekts
* Vererbung mglich wo Substituierbarkeit gegeben ist:
        Eine Untertyp-Instanz ist berall dort einsetzbar, wo eine Obertyp-Instanz gefordert ist.
* dynamisches Binden: erst zur Laufzeit wird bestimmt welche Implementierung einer Operation gewhlt wird.


Zusammenfassung Kapitel 14: Objektrelationale DBs

* Erweiterungen:
        - Large Objects
                # CLOBs: Character Large Objects
                # BLOBs: Binary Large Objects
        - Mengenwertige Attribute
        - Geschachtelte Relationen
        - User Defined Types (UDTs)
                # wertbasierter Typ
                # row Types
        - OID/Referenzen/Pfadausdrcke
        - Vererbung
        - Operationen
* Locator: Pointer auf LOBs, Operationen werden nur logisch ausgefhrt
* Vergleich bei UDTs nur mit gleichen Typen mglich
* Vererbung durch CREATE TYPE ProfessorenTyp UNDER AngestelltenTyp ...
